1. Field of the Invention
The present application relates to wireless communications and in particular to, inter alia, a methods and systems for channel binding parameters that are verified for consistency between a peer and a server.
2. Background Discussion
Networks and Internet Protocol:
There are many types of computer networks, with the Internet having the most notoriety. The Internet is a worldwide network of computer networks. Today, the Internet is a public and self-sustaining network that is available to many millions of users. The Internet uses a set of communication protocols called TCP/IP (i.e., Transmission Control Protocol/Internet Protocol) to connect hosts. The Internet has a communications infrastructure known as the Internet backbone. Access to the Internet backbone is largely controlled by Internet Service Providers (ISPs) that resell access to corporations and individuals.
With respect to IP (Internet Protocol), this is a protocol by which data can be sent from one device (e.g., a phone, a PDA [Personal Digital Assistant], a computer, etc.) to another device on a network. There are a variety of versions of IP today, including, e.g., IPv4, IPv6, etc. Each host device on the network has at least one IP address that is its own unique identifier. IP is a connectionless protocol. The connection between end points during a communication is not continuous. When a user sends or receives data or messages, the data or messages are divided into components known as packets. Every packet is treated as an independent unit of data.
In order to standardize the transmission between points over the Internet or the like networks, an OSI (Open Systems Interconnection) model was established. The OSI model separates the communications processes between two points in a network into seven stacked layers, with each layer adding its own set of functions. Each device handles a message so that there is a downward flow through each layer at a sending end point and an upward flow through the layers at a receiving end point. The programming and/or hardware that provides the seven layers of function is typically a combination of device operating systems, application software, TCP/IP and/or other transport and network protocols, and other software and hardware.
Typically, the top four layers are used when a message passes from or to a user and the bottom three layers are used when a message passes through a device (e.g., an IP host device). An IP host is any device on the network that is capable of transmitting and receiving IP packets, such as a server, a router or a workstation. Messages destined for some other host are not passed up to the upper layers but are forwarded to the other host. The layers of the OSI model are listed below. Layer 7 (i.e., the application layer) is a layer at which, e.g., communication partners are identified, quality of service is identified, user authentication and privacy are considered, constraints on data syntax are identified, etc. Layer 6 (i.e., the presentation layer) is a layer that, e.g., converts incoming and outgoing data from one presentation format to another, etc. Layer 5 (i.e., the session layer) is a layer that, e.g., sets up, coordinates, and terminates conversations, exchanges and dialogs between the applications, etc. Layer-4 (i.e., the transport layer) is a layer that, e.g., manages end-to-end control and error-checking, etc. Layer-3 (i.e., the network layer) is a layer that, e.g., handles routing and forwarding, etc. Layer-2 (i.e., the data-link layer) is a layer that, e.g., provides synchronization for the physical level, does bit-stuffing and furnishes transmission protocol knowledge and management, etc. The Institute of Electrical and Electronics Engineers (IEEE) sub-divides the data-link layer into two further sub-layers, the MAC (Media Access Control) layer that controls the data transfer to and from the physical layer and the LLC (Logical Link Control) layer that interfaces with the network layer and interprets commands and performs error recovery. Layer 1 (i.e., the physical layer) is a layer that, e.g., conveys the bit stream through the network at the physical level. The IEEE sub-divides the physical layer into the PLCP (Physical Layer Convergence Procedure) sub-layer and the PMD (Physical Medium Dependent) sub-layer.
Wireless Networks:
Wireless networks can incorporate a variety of types of mobile devices, such as, e.g., cellular and wireless telephones, PCs (personal computers), laptop computers, wearable computers, cordless phones, pagers, headsets, printers, PDAs, etc. For example, mobile devices may include digital systems to secure fast wireless transmissions of voice and/or data. Typical mobile devices include some or all of the following components: a transceiver (i.e., a transmitter and a receiver, including, e.g., a single chip transceiver with an integrated transmitter, receiver and, if desired, other functions); an antenna; a processor; one or more audio transducers (for example, a speaker or a microphone as in devices for audio communications); electromagnetic data storage (such as, e.g., ROM, RAM, digital data storage, etc., such as in devices where data processing is provided); memory; flash memory; a full chip set or integrated circuit; interfaces (such as, e.g., USB, CODEC, UART, PCM, etc.); and/or the like.
Wireless LANs (WLANs) in which a mobile user can connect to a local area network (LAN) through a wireless connection may be employed for wireless communications. Wireless communications can include, e.g., communications that propagate via electromagnetic waves, such as light, infrared, radio, microwave. There are a variety of WLAN standards that currently exist, such as, e.g., Bluetooth, IEEE 802.11, and HomeRF.
By way of example, Bluetooth products may be used to provide links between mobile computers, mobile phones, portable handheld devices, personal digital assistants (PDAs), and other mobile devices and connectivity to the Internet. Bluetooth is a computing and telecommunications industry specification that details how mobile devices can easily interconnect with each other and with non-mobile devices using a short-range wireless connection. Bluetooth creates a digital wireless protocol to address end-user problems arising from the proliferation of various mobile devices that need to keep data synchronized and consistent from one device to another, thereby allowing equipment from different vendors to work seamlessly together. Bluetooth devices may be named according to a common naming concept. For example, a Bluetooth device may possess a Bluetooth Device Name (BDN) or a name associated with a unique Bluetooth Device Address (BDA). Bluetooth devices may also participate in an Internet Protocol (IP) network. If a Bluetooth device functions on an IP network, it may be provided with an IP address and an IP (network) name. Thus, a Bluetooth Device configured to participate on an IP network may contain, e.g., a BDN, a BDA, an IP address and an IP name. The term “IP name” refers to a name corresponding to an IP address of an interface.
An IEEE standard, IEEE 802.11, specifies technologies for wireless LANs and devices. Using 802.11, wireless networking may be accomplished with each single base station supporting several devices. In some examples, devices may come pre-equipped with wireless hardware or a user may install a separate piece of hardware, such as a card, that may include an antenna. By way of example, devices used in 802.11 typically include three notable elements, whether or not the device is an access point (AP), a mobile station (STA), a bridge, a PCMCIA card or another device: a radio transceiver; an antenna; and a MAC (Media Access Control) layer that controls packet flow between points in a network.
In addition, Multiple Interface Devices (MIDs) may be utilized in some wireless networks. MIDs may contain two independent network interfaces, such as a Bluetooth interface and an 802.11 interface, thus allowing the MID to participate on two separate networks as well as to interface with Bluetooth devices. The MID may have an IP address and a common IP (network) name associated with the IP address.
Wireless network devices may include, but are not limited to Bluetooth devices, Multiple Interface Devices (MIDs), 802.11x devices (IEEE 802.11 devices including, e.g., 802.11a, 802.11b and 802.11g devices), HomeRF (Home Radio Frequency) devices, Wi-Fi (Wireless Fidelity) devices, GPRS (General Packet Radio Service) devices, 3G cellular devices, 2.5G cellular devices, GSM (Global System for Mobile Communications) devices, EDGE (Enhanced Data for GSM Evolution) devices, TDMA type (Time Division Multiple Access) devices, or CDMA type (Code Division Multiple Access) devices, including CDMA2000. Each network device may contain addresses of varying types including but not limited to an IP address, a Bluetooth Device Address, a Bluetooth Common Name, a Bluetooth IP address, a Bluetooth IP Common Name, an 802.11 IP Address, an 802.11 IP common Name, or an IEEE MAC address.
Wireless networks can also involve methods and protocols found in, e.g., Mobile IP (Internet Protocol) systems, in PCS systems, and in other mobile network systems. With respect to Mobile IP, this involves a standard communications protocol created by the Internet Engineering Task Force (IETF). With Mobile IP, mobile device users can move across networks while maintaining their IP Address assigned once. See Request for Comments (RFC) 3344. NB: RFCs are formal documents of the Internet Engineering Task Force (IETF). Mobile IP enhances Internet Protocol (IP) and adds means to forward Internet traffic to mobile devices when connecting outside their home network. Mobile IP assigns each mobile node a home address on its home network and a care-of-address (CoA) that identifies the current location of the device within a network and its subnets. When a device is moved to a different network, it receives a new care-of address. A mobility agent on the home network can associate each home address with its care-of address. The mobile node can send the home agent a binding update each time it changes its care-of address using, e.g., Internet Control Message Protocol (ICMP).
In basic IP routing (e.g., outside mobile IP), routing mechanisms rely on the assumptions that each network node always has a constant attachment point to, e.g., the Internet and that each node's IP address identifies the network link it is attached to. In this document, the terminology “node” includes a connection point, which can include, e.g., a redistribution point or an end point for data transmissions, and which can recognize, process and/or forward communications to other nodes. For example, Internet routers can look at, e.g., an IP address prefix or the like identifying a device's network. Then, at a network level, routers can look at, e.g., a set of bits identifying a particular subnet. Then, at a subnet level, routers can look at, e.g., a set of bits identifying a particular device. With typical mobile IP communications, if a user disconnects a mobile device from, e.g., the Internet and tries to reconnect it at a new subnet, then the device has to be reconfigured with a new IP address, a proper netmask and a default router. Otherwise, routing protocols would not be able to deliver the packets properly.
EAP:
This section sets forth background information related to Extensible Authentication Protocol (EAP). The contents of this section are quotations from the following article, EAP Key Management Framework, Internet Draft Apr. 13, 2006, Aboba, et al, the entire contents of which is also incorporated herein by reference.
“The Extensible Authentication Protocol (EAP), defined in [RFC3748], was designed to enable extensible authentication for network access in situations in which the IP protocol is not available. Originally developed for use with PPP [RFC1661], it has subsequently also been applied to IEEE 802 wired networks [IEEE-802.1X], wireless networks such as [IEEE-802.11i] and [IEEE-802.16e], and IKEv2 [RFC4306].” Id.
“In EAP, keying material is generated by EAP methods. Part of this keying material may be used by EAP methods themselves and part of this material may be exported. The exported keying material may be transported by AAA protocols or used by Secure Association Protocols in the generation or transport of session keys which are used by lower layer ciphersuites.” Id.
“EAP, defined in [RFC3748], is a two-party protocol spoken between the EAP peer and server. Within EAP, keying material is generated by EAP methods. Part of this keying material may be used by EAP methods themselves and part of this material may be exported. In addition to export of keying material, EAP methods may also export associated parameters, and may import and export Channel Bindings from the lower layer.” Id.
“As illustrated in FIG. 1 [see reproduction as FIG. 6 in the present patent application], the EAP method key derivation has at the root the long term credential utilized by the selected EAP method. If authentication is based on a pre-shared key, the parties store the EAP method to be used and the pre-shared key. The EAP server also stores the peer's identity as well as other information associated with it. This information may be used to determine whether access to some service should be granted. The peer stores information necessary to choose which secret to use for which service.” Id.
“If authentication is based on proof of possession of the private key corresponding to the public key contained within a certificate, the parties store the EAP method to be used and the trust anchors used to validate the certificates. The EAP server also stores the peer's identity and the peer stores information necessary to choose which certificate to use for which service.” Id.
“Based on the long term credential established between the peer and the server, EAP methods derive two types of keys: [1] Keys calculated locally by the EAP method but not exported by the EAP method, such as the TEKs; [2] Keying material exported by the EAP method: MSK, EMSK, IV. As noted in [RFC3748] Section 7.10, EAP methods generating keys are required to calculate and export the MSK and EMSK, which must be at least 64 octets in length. EAP methods also may export the IV; however, the use of the IV is deprecated.” Id.
“EAP methods also may export method-specific peer and server identifiers (peer-ID and server-ID), a method-specific EAP conversation identifier known as the Method-ID, and the lifetime of the exported keys, known as the Key-Lifetime. EAP methods may also support the import and export of Channel Bindings. New EAP method specifications must define the Peer-ID, Server-ID and Method-ID. The combination of the Peer-ID and Server-ID uniquely specifies the endpoints of the EAP method exchange.” Id.
“Channel Bindings include lower layer parameters that are verified for consistency between the EAP peer and server. In order to avoid introducing media dependencies, EAP methods that transport Channel Binding data MUST treat this data as opaque octets. Typically the EAP method imports Channel Bindings from the lower layer on the peer, and transmits them securely to the EAP server, which exports them to the lower layer. However, transport may occur from EAP server to peer, or may be bi-directional. On the side of the exchange (peer or server) where Channel Bindings are verified, the lower layer passes the result of the verification (TRUE or FALSE) up to the EAP method.” Id.
“Each key created within the EAP key management framework has a name (a unique identifier), as well as a scope (the parties to whom the key is available). The scope of exported parameters is defined by the EAP peer name (if securely exchanged within the method) and the EAP server name (also only if securely exchanged). Where a peer or server name is missing the null string is used.” Id.
“Certain basic characteristics, known as ‘EAP Invariants’, hold true for EAP implementations on all media: Mode independence; Media independence; Method independence; [and] Ciphersuite independence.” Id.
Mode Independence
“EAP is typically deployed in order to support extensible network access authentication in situations where a peer desires network access via one or more authenticators. Where authenticators are deployed standalone, the EAP conversation occurs between the peer and authenticator, and the authenticator must locally implement an EAP method acceptable to the peer. However, one of the advantages of EAP is that it enables deployment of new authentication methods without requiring development of new code on the authenticator.” Id.
“While the authenticator may implement some EAP methods locally and use those methods to authenticate local users, it may at the same time act as a pass-through for other users and methods, forwarding EAP packets back and forth between the backend authentication server and the peer. This is accomplished by encapsulating EAP packets within the Authentication, Authorization and Accounting (AAA) protocol, spoken between the authenticator and backend authentication server. AAA protocols supporting EAP include RADIUS [RFC3579] and Diameter [RFC4072].” Id.
“It is a fundamental property of EAP that at the EAP method layer, the conversation between the EAP peer and server is unaffected by whether the EAP authenticator is operating in ‘pass-through’ mode. EAP methods operate identically in all aspects, including key derivation and parameter imporVexport, regardless of whether the authenticator is operating as a pass-through or not.” Id.
“The successful completion of an EAP method that supports key derivation results in the export of keying material on the EAP peer and server. Even though the EAP peer or server may import Channel-Bindings that may include the identity of the EAP authenticator, this information is treated as opaque octets. As a result, within EAP the only relevant identities are the Peer-ID and Server-ID. Channel Bindings are only interpreted by the lower layer.” Id.
“Within EAP, the primary function of the AAA protocol is to maintain the principle of Mode Independence, so that as far as the EAP peer is concerned, its conversation with the EAP authenticator, and all consequences of that conversation, are identical, regardless of the authenticator mode of operation.” Id.
Media Independence
“One of the goals of EAP is to allow EAP methods to function on any lower layer meeting the criteria outlined in [RFC3748], Section 3.1. For example, as described in [RFC3748], EAP authentication can be run over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE 802.11 wireless LANs [IEEE-802.11i].” Id.
“In order to maintain media independence, it is necessary for EAP to avoid consideration of media-specific elements. For example, EAP methods cannot be assumed to have knowledge of the lower layer over which they are transported, and cannot be restricted to identifiers associated with a particular usage environment (e.g. MAC addresses).” Id.
“Note that media independence may be retained within EAP methods that support Channel-Bindings or method-specific identification. An EAP method need not be aware of the content of an identifier in order to use it. This enables an EAP method to use media-specific identifiers such as MAC addresses without compromising media independence. Channel-Bindings are treated as opaque octets by EAP methods, so that handling them does not require media-specific knowledge.” Id.
Method Independence
“By enabling pass-through, authenticators can support any method implemented on the peer and server, not just locally implemented methods. This allows the authenticator to avoid implementing code for each EAP method required by peers. In fact, since a pass-through authenticator is not required to implement any EAP methods at all, it cannot be assumed to support any EAP method-specific code.” Id.
“As a result, as noted in [RFC3748], authenticators must by default be capable of supporting any EAP method. This is useful where there is no single EAP method that is both mandatory-to-implement and offers acceptable security for the media in use. For example, the [RFC3748] mandatory-to-implement EAP method (MD5-Challenge) does not provide dictionary attack resistance, mutual authentication or key derivation, and as a result is not appropriate for use in wireless LAN authentication [RFC4017]. However, despite this it is possible for the peer and authenticator to interoperate as long as a suitable EAP method is supported on the EAP server.” Id.
Ciphersuite Independence
“Ciphersuite Independence is a requirement for Media Independence. Since lower layer ciphersuites vary between media, media independence requires that EAP keying material needs to be large enough (with sufficient entropy) to handle any ciphersuite.” Id.
“While EAP methods may negotiate the ciphersuite used in protection of the EAP conversation, the ciphersuite used for the protection of the data exchanged after EAP authentication has completed is negotiated between the peer and authenticator within the lower layer, outside of EAP. For example, within PPP, the ciphersuite is negotiated within the Encryption Control Protocol (ECP) defined in [RFC1968], after EAP authentication is completed. Within [IEEE-802.11i], the AP ciphersuites are advertised in the Beacon and Probe Responses prior to EAP authentication, and are securely verified during a 4-way handshake exchange. Id.
“Since the ciphersuites used to protect data depend on the lower layer, requiring EAP methods have knowledge of lower layer ciphersuites would compromise the principle of Media Independence. Since ciphersuite negotiation occurs in the lower layer, there is no need for ciphersuite negotiation within EAP, and EAP methods generate keying material that is ciphersuite-independent.” Id.
“Algorithms for deriving TSKs must not depend on the EAP method, although algorithms for TEK derivation may be specific to the EAP method. In order to allow a ciphersuite to be usable within the EAP keying framework, a specification must be provided describing how TSKs suitable for use with the ciphersuite are derived from exported EAP keying parameters.” Id.
“It should be understood that an EAP authenticator or peer:
[a] may contain one or more physical or logical ports;
[b] may advertise itself as one or more “virtual” authenticators or peers;
[c] may utilize multiple CPUs;
[d] may support clustering services for load balancing or failover.” Id.
Multiple Ports
“Both the EAP peer and authenticator may have more than one physical or logical port. A peer may simultaneously access the network via multiple authenticators, or via multiple physical or logical ports on a given authenticator. Similarly, an authenticator may offer network access to multiple peers, each via a separate physical or logical port. The situation is illustrated in FIG. 5 [see reproduction as FIG. 6 in this patent application]. Absent explicit specification within the lower layer, EAP keying material and parameters are not bound to a specific peer or authenticator port. Where the peer and authenticator identify themselves within the lower layer using a port identifier such as a link layer address, this creates a problem, because it may not be obvious to the peer which authenticator ports are associated with which authenticators. Similarly, it may not be obvious to the authenticator which peer ports are associated with which peers. As a result, the peer and authenticator may not be able to determine the scope of the EAP keying material. This is particularly problematic for lower layers where key caching is supported.” Id.
“For example, where the EAP peer cannot identify the EAP authenticator, it will be unable to determine whether EAP keying material has been shared outside of its authorized scope, and therefore needs to be considered compromised. There is also a practical problem because the EAP peer will be unable to utilize the EAP authenticator key cache in an efficient way. The solution to this problem is for lower layers to identify EAP peers and authenticators unambiguously, without incorporating implicit assumptions about peer and authenticator architectures. Use of port identifiers is not recommended where peers and authenticators may support multiple ports.” Id.
“In order to further limit the key scope the following measures are suggested:
[a] The lower layer may specify additional restrictions on key usage, such as limiting the use of EAP keying material and parameters on the EAP peer to the port over which on the EAP conversation was conducted.
[b] The backend authentication server and authenticator may implement additional attributes in order to further restrict the scope of EAP keying material. For example, in 802.11, the backend authentication server may provide the authenticator with a list of authorized Called or Calling-Station-Ids and/or SSIDs for which EAP keying material is valid.
[c] Where the backend authentication server provides attributes restricting the key scope, it is recommended that restrictions be securely communicated by the authenticator to the peer. This can be accomplished using the Secure Association Protocol, but also can be accomplished via the EAP method or the lower layer.” Id.
Authenticator Architecture
“The EAP method conversation is between the EAP peer and server, as identified by the Peer-ID and Server-ID. The authenticator identity, if considered at all by the EAP method, is treated as an opaque blob for the purposes of Channel bindings. However, the Secure Association Protocol conversation is between the peer and the authenticator, and therefore the authenticator and peer identities are relevant to that exchange, and define the scope of use of the EAP keying material passed down to the lower layer.” Id.
“Since an authenticator may have many ports, the authenticator identifier used within the Secure Association Protocol exchange should be distinct from any port identifier (e.g. MAC address). Similarly, where a peer may have multiple ports, and sharing of EAP keying material and parameters between peer ports of the same link type is allowed, the peer identifier used within the Secure Association Protocol exchange should also be distinct from any port identifier. While EAP Keying Material passed down to the lower layer is not intrinsically bound to particular authenticator and peer ports, Transient Session Keys (TSKs) may be bound to particular authenticator and peer ports by the Secure Association Protocol. However, a lower layer may also permit TSKs to be used on multiple peer and/or authenticator ports, providing that TSK freshness is guaranteed (such as by keeping replay counter state within the authenticator).” Id.
“This specification does not impose constraints on the architecture of the EAP authenticator or peer. Any of the authenticator architectures described in [RFC4118] can be used. For example, it is possible for multiple base stations and a “controller” (e.g. WLAN switch) to comprise a single EAP authenticator. In such a situation, the “base station identity” is irrelevant to the EAP method conversation, except perhaps as an opaque blob to be used in Channel Bindings. Many base stations can share the same authenticator identity.” Id.
“AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client are always co-resident, this mechanism is applicable to the identification of EAP authenticators.” Id.
“RADIUS [RFC2865] requires that an Access-Request packet contain one or more of the NAS-Identifier, NAS-IP-Address and NAS-IPv6-Address attributes. Since a NAS may have more than one IP address, the NAS-Identifier attribute is recommended for the unambiguous identification of the EAP authenticator.” Id.
“From the point of view of the AAA server, EAP keying material and parameters are transported to the EAP authenticator identified by the NAS-Identifier attribute. Since an EAP authenticator must not share EAP keying material or parameters with another party, if the EAP peer or AAA server detects use of EAP keying material and parameters outside the scope defined by the NAS-Identifier, the keying material must be considered compromised.” Id.
Virtual Authenticators
“When a single physical authenticator advertises itself as multiple “virtual authenticators”, the EAP peer and authenticator also may not be able to agree on the scope of the EAP keying material, creating a security vulnerability. For example, the peer may assume that the “virtual authenticators” are distinct and do not share a key cache, whereas, depending on the architecture of the physical authenticator, a shared key cache may or may not be implemented. Where EAP keying material is shared between “virtual authenticators” an attacker acting as a peer could authenticate with the “Guest” “virtual authenticator” and derive EAP keying material. If the virtual authenticators share a key cache, then the peer can utilize the EAP keying material derived for the “Guest” network to obtain access to the “Corporate Intranet” virtual authenticator.” Id.
“Several measures are recommended to address these issues:
[d] Authenticators are required to cache associated authorizations along with EAP keying material and parameters and to apply authorizations consistently. This ensures that an attacker cannot obtain elevated privileges even where the key cache is shared between “virtual authenticators”.
[e] It is recommended that physical authenticators maintain separate key caches for each “virtual authenticator”.
[f] It is recommended that each “virtual authenticator” identify itself distinctly to the backend authentication server, such as by utilizing a distinct NAS-Identifier attribute. This enables the backend authentication server to utilize a separate credential to authenticate each “virtual authenticator”.” Id.
Key Management
“EAP as defined in [RFC3748] supports key derivation, but not key management. While EAP methods may derive keying material, EAP does not provide for the management of exported or derived keys. For example, EAP does not support negotiation of the key lifetime of exported or derived keys, nor does it support re-key. Although EAP methods may support “fast reconnect” as defined in [RFC3748] Section 7.2.1, re-key of exported keys cannot occur without re-authentication. In order to provide method independence, key management of exported or derived keys should not be provided within EAP methods.” Id.
Parent-Child Relationships
“When keying material exported by EAP methods expires, all keying material derived from the exported keying material expires, including the TSKs. When an EAP re-authentication takes place, new keying material is derived and exported by the EAP method, which eventually results in replacement of calculated keys, including the TSKs. As a result, while the lifetime of calculated keys can be less than or equal that of the exported keys they are derived from, it cannot be greater. For example, TSK re-key may occur prior to EAP re-authentication. Failure to mutually prove possession of keying material during the Secure Association Protocol exchange need not be grounds for deletion of the keying material by both parties; rate-limiting Secure Association Protocol exchanges could be used to prevent a brute force attack.” Id.
Key Strength
“In order to guard against brute force attacks, EAP methods deriving keys need to be capable of generating keys with an appropriate effective symmetric key strength. In order to ensure that key generation is not the weakest link, it is recommended that EAP methods utilizing public key cryptography choose a public key that has a cryptographic strength meeting the symmetric key strength requirement.” Id.
References:
The present invention provides a variety of advances and improvements over, among other things, the systems and methods described in the following references, the entire disclosures of which references are incorporated herein by reference.
1. [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
2. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP)”, RFC 3748, June 2004.
3. [RFC4306] Kaufman, C., “Internet Key Exchange (IKEv2) Protocol”, RFC 4306, December 2005.
4. [I-D.ietf-eap-keying] Aboba, B., “Extensible Authentication Protocol (EAP) Key Management Framework”, draft-ieff-eap-keying-09 (work in progress), January 2006.